The real-time simulation of complex, dynamic models places high demands even on modern computation nodes on account of the tight temporal boundary conditions. By way of example, such models are employed in automotive hardware-in-the-loop simulations (HIL) and in the field of automotive rapid control prototyping (RCP), where fast control loops have to be closed. In the case, too, of controlled systems having a high dynamic range, such as in the case of electric motors, for example, short cycle times and low latencies are indispensible. These are now virtually impossible to implement solely with CPU-based simulations that run on a CPU of a computation node (CN). On the basis of CPU-based processing in a computation node the term CN is also used generally for the CPU.
A programmable logic circuit, often designated as programmable logic device or PLD for short in the specialist literature is an electronic component for integrated circuits. In contrast to logic gates having a prescribed fixed function, PLDs obtain their function only after manufacture by means of the corresponding programming (configuration). Simple programmable logic circuits usually consist of an array of AND logic combinations followed by an array of OR logic combinations. They include for example programmable read-only memory (PROM), programmable array logic (PAL) or generic array logic (GAL), and programmable logic arrays (PLA). In the case of a PLA, both the AND array and the OR array are programmable. The complex programmable logic device (CPLD) and field programmable gate array (FPGA) are known as programmable logic circuits of higher complexity. CPLDs such as FPGAs often offer programmable I/O cells which allow various signal interfaces to be connected.
Accordingly, for example PLDs, in particular FPGAs, can provide support as additional hardware components in real-time simulation by virtue of their performing the calculation of dynamic parts of a model. As a result of the high flexibility and possibility of parallel processing of signals, even hard real-time requirements can easily be fulfilled by the use of PLDs, in particular FPGAs. The PLDs can generally serve as hardware accelerators for supporting CPUs.
There are two basic possibilities for the use of the PLD, in particular an FPGA. In a first operating mode (manufacturer mode), a fixed functionality is loaded onto the PLD, in particular an FPGA, as a result of which the PLD, in particular an FPGA, is configured. Said fixed functionality is usually provided by a manufacturer of a corresponding system and is designated hereinafter as first PLD code. By way of example, I/O channels having a fixed functional scope are provided by means of said fixed functionality, such that the I/O channels can be used in an application in the CN. An application on the processor of the CN can access the fixed PLD functionality and the I/O channels.
A method for generating an overall netlist in the manufacturer mode is illustrated in a simplified manner by way of example in FIG. 1. Accordingly, in a first step S1, designated here as “design entry”, a PLD code, designated here as “manufacturer code”, is created, which contains provided functionality. An interface logic for communication with the CN is additionally provided. The PLD code and the interface logic can also be created as one code block. In a second step S2, designated here as synthesis, an overall netlist is generated from said PLD code. In a further, third step S3, implementation, comprising the steps of placing and routing, a bit stream for use in the FPGA is generated, inter alia, from said overall netlist. The entire method can be carried out by a system manufacturer for example; the user then obtains only the bit stream for use in the FPGA.
In a second operating mode (user mode), which is likewise illustrated in a simplified manner by way of example in FIG. 2, in a first step S1, designated here once again as “design entry”, a model is created which contains functionality provided by the user. This PLD code is designated hereinafter as second FPGA code or generally as second PLD code. In a second step S2, designated here as synthesis, with the incorporation of the interface logic, an overall netlist is generated from said model. In a further, third step S3, implementation, a bit stream for use in the FPGA is generated, inter alia, from said overall netlist. The second PLD code, which is thus created in a model-based manner by the user and uses for example the I/O channels in the FPGA, can then be loaded onto the FPGA. The PLD code may be for example a control model on the FPGA or a preprocessing of the I/O channels in the FPGA. This method is advantageous, for example, if the interface logic is provided by the apparatus manufacturer. In that case the user need only create the model and carry out the rest of the method. By contrast, the user need not be concerned with the linking of the FPGA interfaces.
In this context, a particularly advantageous method for connecting I/O channels that are not explicitly used is known for example from DE 10 2013 104 320 A1.
A further illustration of the first two methods is shown in FIG. 3. Accordingly, a CN interface 12 to a computation node is provided on an FPGA 10. In addition, in the first operating mode the manufacturer code 16 and in the second operating mode the user model 16 are located on the FPGA. Data exchange between the manufacturer code 16 or user model 16 and the computation node is possible via the CN interface 12. The FPGA can receive and/or output data via I/O channels 14. Received data can be processed by the manufacturer code 16 or user model 16 and be forwarded to the computation node via the CN interface 12.
A combination of manufacturer code and user code by the incorporation of code which is presynthesized by of the manufacturer and which is typically provided as a netlist has the advantage that this PLD code is already “finished” and can easily be incorporated by the user. What is disadvantageous about that is that the code on the part of the manufacturer then always occupies the entire space in the FPGA to provide a corresponding default functionality. Accordingly, a reduced space is available on the FPGA for PLD code of the user. A use of a larger FPGA is associated with correspondingly higher costs, and is therefore usually ruled out for this reason. As a result, reserves for later extensions or bug fixes are already used up at the beginning. Furthermore, it should be taken into consideration that compile times increase more than proportionally when the FPGA has a high occupancy level, i.e. with increasing occupancy of the FPGA, such that a corresponding utilization of the FPGA should be avoided in practice. This holds true all the more in the case of applications in the RCP environment which experience frequent changes.
One method known per se for incorporating only that part of the first PLD code which is actually utilized consists e.g. in the utilization of “generate” instructions. However, the latter do not function with presynthesized code, i.e. if the first PLD code is provided by the manufacturer typically as a netlist. However, providing the first code as a first netlist is important in order that build times for the overall netlist made from the first and second PLD codes are kept short. Depending on the functionality, build times of several hours just for the first PLD code on the part of the manufacturer are entirely possible. It is thus necessary to take a decision as to whether presynthesized code, i.e. typically the first netlist, will be utilized to shorten the creation of the overall netlist, or whether the first PLD code can be fixedly shortened in order to have more capacities available for the user model, in which case the build times are correspondingly lengthened considerably.